Now that Bolo has a proper map file format defined, let's see no more of the boring 100 x 50 rectangular maps. When James Everard designed the standard map in 1987 Bolo ran on a BBC micro with 32K RAM and a 0.2 MIPS 6502 processor. Also, maps DON'T have to be huge. Games played on small interesting maps are much more fun. Just don't make the islands rectangular all the time. Can we see some imagination and creativity please?
• "How big can Bolo maps be?"
The Bolo world is 236 map squares across from east to west and 236 map squares tall from north to south. Players cannot go outside this area (accidentally or deliberately) because of the floating sea mines that surround the playing area. There is also an enforced rule that there can be no land within ten squares of the boundary, which limits map designers to working within a 216x216 square.
• "Why don't you allow bigger maps?"
The 216x216 allowable map area is already bigger than necessary for a 16 player game. Large maps are usually boring because the players spend most of their time driving around looking for opponents. There is also no reason that maps have to be square or rectangular. Good map designers can make small maps that are interestingly shaped and fun to play on. Very small maps can lead to very quick fast paced games. Medium sized maps lead to longer games. Large maps can lead to games that take so long that people get bored and leave.
• "If I design a map intended for a large number of players, should I put lots of refuelling bases on it?"
Bolo tries to be relatively self-adjusting for different numbers of players. The rate at which each refuelling base generates supplies at any given moment is proportional to the number of players in the game at that time. If more players join a game then each base will generate supplies at a proportionately faster rate. This means that a map with 16 refuelling bases on it will be resource rich, even if there are lots of players in the game. Similarly, a map with only three or four refuelling bases on it will be resource poor, even if there are only two players. The same thing applies to forest growth. The more players there are in a game the faster the forests grow, to counteract the fact that there are more people consuming building materials. This is not particularly realistic, but it is necessary, or two player games would be rapidly overrun with uncontrollable forest growth, and ten player games would be quickly stripped of all trees.
• "Where should I put deep sea on my map?"
Deep sea should surround the island(s) of your map. While it is possible to have deep sea anywhere, it is not usually placed in the interior of islands except in novelty maps. The purpose of deep sea is to mark the boundaries of the playing area. On land and shallow water, players are more or less free to build as they please, but deep sea is unchangable. This helps to maintain the character of your map design by placing limits on the playing area and stopping players from building unlimited structures out into the water and arbitrarily changing the topology of your island(s).
• "Can I put mines on my map?"
You can put mines on your map and they will be honoured by Bolo when the map is loaded. Whether or not the players get to see the mines is determined by the game settings chosen by the person who starts the game.
Questions and Answers about Writing Brains
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This list compiled by Kovas Boguta <VISITOR@uicws.phy.uic.edu>
• "What is the basic clock rate for Bolo?"
The basic "tick" in Bolo is 1/50th second.
• "How is the firing for pillboxes controlled?"
A pillbox fires once every x ticks. For a quiescent pillbox x is 100 (two seconds). Each time it is hit, x halves, down to a minimum of 4 ticks (12.5 shots per second). x 'relaxes' back to the quiescent state at a rate of one unit every 32 ticks.
Pillboxes will shoot at you if you are within 8 map squares (2048 World units).
Pillbox shots go nine map squares (2304 World units).
• "How is refuelling controlled?"
Refuelling bases refuel a tanks armour first, then shells, then mines. Armour is repaired at the rate of at most one unit per second. Shells and mines refuel at a rate of at most ten per second. (These rates may be lower in practice due to network delays.)
Every twenty seconds refuelling bases replenish their stocks by one unit per player in the game. For example, if there are five players in the game, then refuelling bases will replenish by five units every 20 seconds.
• "What are the various maximum speeds of things in Bolo?"
The speed of a bullet is 32 World units per tick. The top speed of a tank on a boat is 16 World units per tick. Some other speeds are:
Terrain Tank speed Man speed
BUILDING 0 0
RIVER 3 0
SWAMP 3 4
CRATER 3 4
ROAD 16 16
FOREST 6 8
RUBBLE 3 4
GRASS 12 16
HALFBUILDING 0 0
BOAT 3 16
REFBASE/PILLBOX 16 16
• "What example brain code is available and where can I get it, and what other
documents have information on writing brains?"
There is publicly available code of Indy 1.0, Standard Autopilot, Headset,
Ricklesbot, Decayed Brain. Also, there is the Bolo Brain Message Parsing
Library. Of these, only Indy and Standard Auto are full brains, while Headset
and Ricklesbot are `borgs. Decayed Brain only captures bases so it cant be
considered a full bot. Most of these can be found at the various bolo ftp sites.
Standard Autopilot is included in the Bolo package along with documentation on
how to write brains.
• "Can you really only allocate 32K of memory from the heap? It seems Indy
2.02 allocates it out of Bolo's heap, instead of from Multifinder temporary
memory?"
No, there is not a limit. You do have to increase the Bolo Application
partition though. Both Ladmo and Indy allocate memory from the
Bolo Application heap. DK'd Brain, on which Ladmo is originally based,
took temporary memory from the system, through the use of temphandles.
I forget what version, but I changed Ladmo to take from the Bolo heap instead,
because of a couple of reasons: a bit easier to determine how much memory
is available, memory available is less likely to change, if it crashes
it takes down only Bolo and not the whole system.
• "What starting information is passed to the brain? I couldn't find this,
but I remember something about bases only."
First look at the Brain.h. The BrainInfo is passed on every think call,
and in the Brain.h Stuart describes more on what is passed and when. When
starting a game it is just like any other time, you are passed what you own,
what you see and the location of the neutral bases.
• "Is there a way to access the map information? If other players have
played/seen the map before, the brain should have the same advantage."
The only Brain I have seen that load in the map ahead of time is
"Will's Brain" by Will Uther which is not longer in production. Will
is now working with me on Ladmo. I don't know if Ladmo will have this
feature in a later version, we haven't discussed it yet. Anyway, Stuart
provides the structure of map files in the Bolo package. If you wanted
the option to load in the map you can add it.
• "Is there a way to tell when a neutral, or hostile, pillbox has been
taken?"
Nope, and it is a bummer. The only way to tell is by seeing it happen or
seeing it gone later.
• "Can a brain tell how many neutral bases remain?"
Yes. If the person starting the game sets the "give brians an advantage"
option you get passed the location of all the bases on each THINK call.
So you can of course count up how many are neutral.
• "Do bots have access to audio information?"
No.
• "I notice that my brain sometimes crashes when control is transferred
from my brain back to Bolo. Is it possible that there are some memory
operations or writes to the info/message struct which may cause Bolo
to crash? I originally though that I was overrunning my allocated memory,
or doing something inadvertently with memory allocated by way of NewPtr,
but am starting to doubt this."
Sounds like you are writing to somewhere you shouldn't be. I've had
problems with crashes when I call NewHandle (and not have enough memory).
I think this might be a fault with Bolo's Grow function (whatever it's
called) since it bombs if I request more memory than Bolo has been
allocated.
Also check to make sure that you are not modifying the Quickdraw Globals.
This could be a no no (Although changing the message text font is sometimes
interesting...)
• "The crashes are usually accompanied by the (unhelpful) floating point
co-processor not installed (ID 25) system crash message."
This is probably a problem in your brain. By any chance you have some
floating point calls and 'Generate 68881 instructions' checked in Think C.
• "Is it possible for messages sent in rapid succession (eg on successive
think calls) to become scrambled/lost/truncated during transmission? Also,
is it possible to send/recieve the full 0x01 to 0xFF character range,
or only a subset thereof? I have found messages containing compressed map
data to suffer from losses/scrambling every now and then even though the
decoding/encoding algorithms are compatible when run together in
another application."
YES. You really need to watch out for this. Once a message has been sent,
Bolo blanks out the sendmessage field (Data->sendmessage[0]==0). So just
check this before sending a new packet.
I think you can send characters from 0x01 to 0xff. However some characters
will look weird on the other player's end (Make sure you don't send the
